This invention relates to a method of and system for crediting an online publisher in an affiliate marketing relationship.
Online marketing is driven by performance measurement. The generally accepted practice is to use persistent cookies to track visitor referrals and sales behavior. A cookie, when used in respect of the Internet, refers to a small text file of information sent by a web server to a web browser that the browser software is expected to save and to send back to the server whenever the browser makes additional requests from the server. A cookie can only be retrieved and opened either by the web server that set it on the web browser, or locally by the owner of the machine that the web browser is hosted on.
In affiliate marketing, which is a common business methodology for driving visitors to advertising sites and which will be described in further detail below, cookies are leveraged to track the origin of the visitor with the intention of compensating the referring publisher/s for referring visitors to advertisers. In this regard, a cookie can contain information such as referring affiliate and network identifications, user identification, user preferences, archive shopping cart information, and other personally identifiable information.
A typical affiliate marketing relationship comprises the following three components:    1. The publisher, which is the affiliate site carrying the advertisers advertising.    2. The advertising network, which is the 3rd party tracking solution that serves the advertisements on the publisher's site/s, and tracks the performance of the advertisements.    3. The advertiser, which is the site on which the transaction is ultimately concluded.
The process flow in a typical affiliate marketing relationship will now be described with reference to FIG. 1. When a user/visitor visits a publisher website using his/her web browser, as indicated by action arrow 10, and clicks on a tracked advertisement served by the advertising network, the associated URL directs the visitors web browser to the advertising network's server, as indicated by action arrow 12. The advertising network's server sets a tracking cookie containing the publisher's tracked advertisement identification and a timestamp on the visitor's browser, as indicated by server request arrow 14. The advertising network's server then redirects the visitor's browser to the advertiser's website landing page, as indicated by redirect arrow 16.
After allowing the user/visitor to conclude the required action/s or transaction/s on the advertiser's site, the advertiser's website launches a confirmation page containing an advertising network pixel tracking integration code including variables for a transaction identification, an amount (if a sale took place), and other variables as determined necessary. This is indicated by action arrow 18.
The transaction is then reported to the advertising network's server, as indicated by server request arrow 20, with the pixel tracking integration code also being sent to the advertising network at this stage. The advertising network's server then checks the visitor's browser for a previously set advertising network cookie containing the publisher's tracked advertisement identification. If the cookie is found, the advertising network's pixel integration code writes the transaction, including the referring publisher's advertisement identification, transaction identification, the amount (if a sale took place) and other required variables into an advertising network database. This database is accessible by both the publisher and the advertiser so that each party can see the number of advertisements served, clicks, leads, sales or any other required actions generated.
In cases where multiple cookies from different publishers are found by the advertising network, the advertising network's business rules determine which publisher is allocated the sale, generally based on the timestamp in the cookie.
When running multiple advertisement network campaigns, the advertiser is expected to ensure that each advertising network's pixel integration code is embedded on the advertiser confirmation page to track each campaign. This, however, poses a number of problems, which will now be described:
Problem 1: Duplicate Transactions
Should a visitor web browser contain tracking cookies from multiple advertising networks and conclude a transaction, resulting in the confirmation page being displayed, it is highly likely that all the advertising networks' pixel tracking codes would be triggered and the advertising networks that found cookies showing referral information would write the transactions into their databases, as described. This would result in multiple networks showing the same transaction. To address this, a manual validation process by the advertiser to remove the duplicate transaction from the advertising networks would be required. However, in this regard, the advertiser would most likely not know the dates that the individual advertising networks' cookies were set on the visitor's web browser, and therefore would not be able to accurately determine which of the transactions to remove. This, in turn, would result in the advertiser erroneously removing transactions from deserving publishers.
One way of addressing this would be for the advertiser to set up individual confirmation pages for each of the advertising networks that it runs campaigns on. However, this option would require advanced customization to the advertiser's shopping cart, but most shopping cart software providers do not allow this practice.
Another way to address is to set up server side visitor tracking. This option, however, would further require setting up separate landing pages for each advertising network and the implementation of web server side visitor cookie tracking to ensure that if a transaction was not concluded and the visitor returned at a later date that the visitor's browser would be redirected back to the same landing page. In addition, this server side tracking would need to integrate into the shopping cart to ensure that only the referring advertising network's pixel was posted which would ensure the referring publisher was credited. Thus, this option requires advanced customization of the website and shopping cart, and is technically difficult, with the associated costs most likely tending to be prohibitive.
A further way to address this problem is to set up multiple shopping carts for each advertising network it runs campaigns on. However, again, this option would require customization and would also be expensive as it would require a software license for each shopping cart implemented. In addition, it would not address the issue of misappropriating sales, as returning visitors may not be directed back to the same shopping cart to conclude a transaction and as a result the transaction may not be recorded at all, or misappropriated to another channel or publisher.
Problem 2: Publisher Fraud
Should a visitor web browser contain tracking cookies from multiple advertising networks and conclude a transaction, resulting in the confirmation page being displayed, it is highly likely that all the advertising networks' pixel tracking codes would be triggered and the advertising networks that found cookies showing referral information would write the transactions into their databases, as described. Significantly, publishers that are members of multiple advertising networks could set multiple network cookies on a visiting web browser when an advertisement is triggered. This is done through a process called Cookie Stuffing or IFraming. An IFRAME is HTML code that inserts a floating frame within a Web page which is not bound to the side of a browser window. This IFRAME can be sized to 1 pixel high by 1 pixel wide and as a result would be invisible to the visitor viewing the web page using web browser software. Within the IFRAME the publisher could however trigger the launch of multiple advertising networks links, which would result in multiple advertising networks' cookies being set. Though the visitor would not be aware of this, the visitor's web browser would accept all these cookies and save them for future retrieval by the advertising networks.
As a result, should a visitor web browser contain tracking cookies from multiple advertising networks and conclude a transaction, resulting in the confirmation page being displayed, as described above, it is highly likely that all the advertising networks' pixel tracking codes would be triggered and the advertising networks that found cookies showing referral information would write the transactions into their databases. This would result in multiple networks showing the same transaction.
One way of addressing this would involve a manual validation process by the advertiser to remove the duplicate transactions from the advertising networks. However, the advertiser would most likely not know the dates that the individual advertising networks cookies were set on the visitor's website, and therefore would not be able to accurately determine which of the transactions to remove.
In addition, it would be difficult to prove whether a particular publisher was intentionally cookie stuffing, which would result in fraudulent affiliates with poor business practices remaining contracted to deliver transactions to the advertiser. Clearly, a side effect of this behavior is to undermine advertising outside the affiliate marketing channel.
Problem 3: Generating False Transactions
Should a publisher be able to identify the HTML link taxonomy used by the advertising networks, fraudulent publishers could take advantage of this by triggering the advertising networks pixel to generate false transactions by inserting fraudulent transaction identifications, amounts and other variables. This is generally done using advertising networks that do not offer domain validation to ensure that the advertising network integration pixel code is triggered only off the advertiser's valid domain.
Problem 4: Real Time Data Aggregation
Running multiple advertising network campaigns results in disparate sets of data that need to be manually reconciled and aggregated to ensure that reporting is synchronized. Each network has its own proprietary reporting interface and requires manual intervention to select and download reports. There is no interoperability standard or standard naming convention, and so centralizing and aggregating the data reported requires additional manual intervention to collate the data into spreadsheets or a data warehouse, from where reports across the multiple platforms can be generated. Significantly, these reports are not in real time, as the reports can only be generated intermittently and require manual intervention to check and remove duplicate sales prior to centralizing the reporting. Additionally not all platforms update their statistics and reporting in real time, resulting in skewed reports with data that does not match to the advertisers' transaction information.
Problem 5: Flawed Business Intelligence on Which to Base Decision Making
Resulting from the lack of real time data aggregation, advertisers are forced to make business critical decisions on incomplete transaction and management information. There is no way to independently benchmark performance across multiple advertising networks or campaigns and optimize performance in real time. This lack of information results in decisions being made based on historical or out of date business information that impacts the advertisers' ability to rapidly respond to fluid market conditions.